Date: Sun, 5 Jun 94 04:30:02 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #110 To: tcp-group-digest TCP-Group Digest Sun, 5 Jun 94 Volume 94 : Issue 110 Today's Topics: Announce: JNOS/Linux ALPHA.4 problem with wampes Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Sat, 04 Jun 1994 20:04:45 -0400 From: "Brandon S. Allbery" Subject: Announce: JNOS/Linux ALPHA.4 To: nos-bbs@hydra.carleton.ca By the time you receive this, the ALPHA.4 release of JNOS/Linux should be in the incoming directory at ucsd.edu. The complete path name is ucsd.edu:/hamradio/packet/tcpip/incoming/j109lxA4.tgz This, like ALPHA.3, is a full source release; however, the DOS-specific files have been omitted from this release. A summary of the changes since ALPHA.3 follows my .signature. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org The FUDs at Microsoft are shouting "Kill The Wabi!" Bugfixes and changes since ALPHA.3: * "ls"/"dir" of nonexistent file/directory no longer kills NOS I was using a findlast() function to close the directory opened by the findfirst()/findnext() clone, but they already close the directory on EOF or failure. There may now be file descriptor leaks if findfirst()/ findnext() is not run in a loop until -1 is returned, but the code to cope with this already exists: a flag is now set to make sure the directory isn't closed twice. * Telnet now works right with *ix clients I adapted the 1.10 patches for 1.09. The same caveats apply as with 1.10. * Partial support for FTP "SYST" command All that is currently done by the client is to print the system type as a reminder to the user. I will implement *ix-like automatic file type setting later. The server responds to "SYST" with a 215-level response similar to that in 1.10c. * New asy driver The loss of large packets is now cured: EAGAIN/EWOULDBLOCK wasn't being trapped on writes. Also, the driver parameters can now be configured at runtime so that one can balance between the ALPHA.1 behavior, which tended to "hog" the process servicing busy asy ports, and the ALPHA.2 behavior which preferred the other tasks but could drop incoming packets on a very heavily loaded frequency. The "asy" command now honors the buffer length. Previously, a fixed-size 64-byte buffer was used (traditional *ix clist size). It can be changed dynamically with the "asyconfig" command. Smaller buffers improve the response of other NOS tasks but eat more CPU time; larger buffers will better keep up with busy channels but will "starve" other NOS tasks (you can use "rxqueue" below to avoid this, however). A good setting is a little larger than your "paclen" (or the MTU on a SLIP/PPP link). The input and output tasks now support a simple form of inter-task flow control, using the "rxqueue" and "txqueue" parameters: after "rxqueue" packets are put in the network "hopper" by the asy receive task, it blocks; after "txqueue" packets are transmitted by the asy transmit task or if EAGAIN/EWOULDBLOCK is returned on a write, it blocks. The default is the ALPHA.3 behavior, which is an rxqueue/txqueue of 1. For the "hoggy" style used by ALPHA.1, set rxqueue and txqueue very large. I have both set to 5 on my asy links and to 2 on my SLIP-to-Linux link, and it seems to be a fairly good compromise. The "asystat" command now shows some useful statistics that may be of help in tuning these: net> asystat 144.99: 9600 bps, packet size 255, RTS/CTS disabled, carrier disabled RX: ints 2 chars 73 puts 2 buf 1024 rxqueue 5 qlen 0 ovq 0 block 0 TX: ints 1 gets 0 chars 57 txqueue 2 qlen 0 ovq 0 block 0 linux: 38400 bps, non-blocking, RTS/CTS disabled, carrier disabled RX: ints 0 chars 0 puts 0 buf 1024 rxqueue 2 qlen 0 ovq 0 block 0 TX: ints 0 gets 0 chars 0 txqueue 2 qlen 0 ovq 0 block 0 "ints" is the number of times pwait() returned control to the task, indicating that select() detected pending data on input or a packet became available for output. "chars" is the number of characters read/written. "buf" is the current receive buffer size, as specified in the attach statement or the "asyconfig" command. "rxqueue"/"txqueue" is as described above. qlen is the instantaneous queue size (number of packets). ovq is the number of times queue flow control (described above) was triggered. "block" is the number of times read/write tried to block (in the case of reads, the number of times it tried to block after data was claimed to be available). The "asyconfig" command can be used to examine or set the new asy configuration parameters: asyconfig [] is any asy interface. is one of: bufsize receive buffer size rxqueue receive flow-control threshold txqueue transmit flow-control threshold Any of these can be changed at any time. RTS/CTS flow control is now supported, but untested; I don't have anything conveniently available which supports it to test it. As with the DOS version, it is controlled with param RTS <0|1> The default is 1, for compatibility with previous Linux releases. The DOS DTR parameter will *not* be supported, because the Linux serial driver has effectively complete control over DTR. In addition, a new input mechanism has been provided, using the "f trigger" parameter used by the DOS version for 16550A FIFO control (that function is handled by the Linux kernel; get the "setserial" package if you need to tune the FIFO trigger level). The value can range from 0 to 255; if it is 0, the original input mechanism is used, otherwise blocking reads are used with termios VMIN set to the specified value. At the moment there is no error checking; if you set the buffer size smaller than VMIN you could lose incoming data. Under some *ixes setting it to anything other than a multiple of VMIN could cause problems. (I know that under Ultrix, you would need to set bufsize equal to VMIN --- but I don't think JNOS has been ported to Ultrix yet :-) The tradeoff here is that, on a mostly quiet channel, input could be delayed by up to 1/5 second, but on an active channel JNOS will use *much* less CPU time and generally will be much more efficient. Summary of the current "attach" command: attach asy ttySX - [] The argument after the device ttySX should be zero or a hyphen (-). It may be used in future versions. The device should be a ttySX, not a cuaX. cuaX can cause problems for reasons I don't fully understand at present. is the read buffer size described above. The only s supported are "v" for Van Jacobsen SLIP compression and "f triglevel" to use the VMIN read mechanism. * The Command flow-control throttle from incoming mail has been fixed All previous fixes tried to avoid the use of an asynchronous I/O mechanism, since it complicates the "curses" session manager. Unfortunately, there *is* no proper fix that doesn't involve asynchronous I/O, since the messages are inherently asynchronous. There is now an asynchronous output entry point in the session manager, which is used for these messages. * The FTP client "lcd" command no longer fails dir_ok() wasn't setting up variables properly. Sometimes this resulted in a "harmless" failure; other times NOS dropped core. * JNOS will read the config file ".nosrc" if no -f option is specified This is primarily to support default session managers (see below), but may also be used for color information in the future. You may also want to copy compat.cfg to .nosrc if you still don't want to rearrange your files from ALPHA.2. * You can specify the default Command and Trace session managers in the config file (either .nosrc or the one read with the -f option). Command = sessmgr[:options] Trace = sessmgr[:options] Additionally, a number of "dead ends" were pursued but are no longer in the source. These include color support (the color commands were asynchronous to the output, resulting in scrambled colors) and a trace server (a positive feedback loop results if someone tries to trace the interface they're on, and there's no way to prevent it). The abortive color support did lead the way to the answer to the Command flow-control problem, however (if you've been paying attention, you'll note that it's the same problem in reverse). Another reason color was dropped is that ncurses presently ignores background colors. ------------------------------ Date: Sat, 4 Jun 1994 13:10:50 +0100 (MET DST) From: pe1ayx@pe1ayx.knoware.nl (Hans Alblas) Subject: problem with wampes To: tcp-group@UCSD.EDU I have a problem with the wampes software When wampes recieves fragmented upd frames with ip-ip encapse headers then wampes will hangup for some time. While recieving the first udp frame fragment goes wampes in a waitstate (the first recieved fragmanted udp frame piece is not shown in the trace at this moment) after some time (when all fragmentation pieces are together) will the system run's again normal but on our slowly radio net will it take some time befor wampes is out of his hangup situation. How can i resolve this problem? In this situation is it impossible to get een zone domain transfer from a domain server via a wampes gate even via fast Internet! Groetjes de Hans -- Hans Alblas Email: pe1ayx@pe1ayx.knoware.nl Egstraat 34 Packet: pe1ayx@pi8hrl.ampr.org 6418JA Heerlen IP: [44.137.4.10] (AmPR-Net) ------------------------------ End of TCP-Group Digest V94 #110 ******************************